FIG. 1 is an illustrative drawing representing a mixed signal schematic design hierarchy 100 used during capture and display of an integrated circuit (IC) design and a corresponding netlist module hierarchy 101 used for input to an IC simulation tool. The example schematic design hierarchy and the example netlist hierarchy are encoded in a computer readable storage device. A visual representation of the design hierarchy may be produced on a computer display screen. The netlist hierarchy 101 conveys connectivity information among instances and nets within the design hierarchy and is suitable as input to a circuit simulation tool.
A circuit designer or design team uses graphical program design tools to create a schematic circuit design hierarchy, which provides a graphical visual representation of circuit behavior in terms of circuit components and their connections. Analog components typically are represented graphically within the schematic design 100. Digital components often are represented with text blocks using a hardware description language (HDL) such as VHDL, Verilog or Verilog-AMS (hereinafter ‘VAMS’), for example.
A top ‘view’ (or ‘scope’) 102 within the schematic design 100 may contain analog blocks, digital blocks or a mix of analog and digital blocks. FIG. 2 is an illustrative schematic diagram showing example details of view 102 of FIG. 1 that includes a digital block 202, an analog block 204 and a net 206 that interconnects the two blocks. The digital block 202 includes a digital gate 208. The analog block 204 includes analog components, a capacitor 210 and an inductor 212. The net 206 is shared between the two blocks 202, 204.
In a hierarchical design, schematic representations of components at a more abstract higher level of a design hierarchy instantiate design blocks lower in the hierarchy. Referring again to FIG. 1, blocks 202 and 204 within view 102 instantiate design blocks 104 and 106. Design block 104 instantiates design blocks 108 and 110. Design block 106 instantiates design block 112. As a result, design blocks disposed higher up in more abstract levels of the design hierarchy hide design details within corresponding design blocks disposed at lower less abstract levels of the hierarchy. In a cell-based IC design, repetitive blocks of circuitry are represented by cells that may be accessed from a design cell library. Cells disposed higher in an IC design hierarchy may contain instances of other cells lower in the hierarchy. Schematic design cells disposed higher in a design hierarchy hide from the user much of the detail and complexity of design cells lower in the hierarchy.
In order to test a design, the schematic design hierarchy is converted to the netlist hierarchy 101, which serves as input to a simulation tool used to simulate behavior of a circuit implemented according to the design. The netlist hierarchy 101 includes a plurality of text modules that correspond to views within the design hierarchy 100. The modules of the netlist include HDL text representations of the corresponding blocks of the design hierarchy that are suitable for use with a simulation tool used to simulate behavior of the circuit represented by the design hierarchy. Netlist module 122 corresponds to design view 102. Netlist module 202′ corresponds to design block 202 and instantiates netlist module 124, which correspond to design blocks 104. Netlist module 204′ corresponds to design block 204 and instantiates netlist module 126, which corresponds to design block 106. Netlist module 124 instantiates netlist modules 128 and 130, which correspond to design blocks 108 and 110, respectively. Netlist module 126 instantiates netlist module 132, which corresponds to design blocks 112.
The modules of a mixed signal netlist hierarchy typically consist of text in a digital HDL, such as VAMS, that is suitable for representation of digital design information. Accordingly, graphical representations of analog components of a mixed signal design hierarchy ordinarily are converted to a digital HDL text representation within the netlist hierarchy. The conversion from design schematic to netlist must account for components within the schematic design which are shared between analog and digital partitions. In addition, a schematic design block that represents an analog component may be annotated with one or more text statements that provide auxiliary model information, sometimes referred to a CDF (component description format) information, such as library information or instructions for the simulator, for example. These annotations may reference information, sometimes included as PDKs (process design kits), which is supplied by a foundry that is to manufacture the circuit, for example. The translation of a mixed signal design hierarchy to a netlist hierarchy also must account for these annotations.
FIG. 3 is an illustrative drawing of a system to convert an AMS (analog-digital mixed signal) schematic design used in design capture to a digital HDL netlist used in design simulation in accordance with certain prior art. A schematic representation of a circuit design encoded in computer readable storage device 302 can be displayed graphically on a computer display screen (not shown). A computer system is configured to implement a netlister 306.
The netlister 306 is configured to receive as input schematic design information, reference library information and PDK/CDF information encoded in storage devices 304, 308 and 310. The netlister 306 translates the schematic design 302 to a netlist in a digital design text language such as VAMS, which is encoded in storage device 312. A simulation environment 314 produces analog control statements that are stored in computer readable storage device 316. Digital models expressed in HDL language are stored in storage device 318. A simulator 320 configures a computer system to receive as input the netlist, the analog control statements and the digital models and to use these inputs to run a simulation of the circuit design 302.
The simulation environment 314 is produced by configuring a computer system to implement a module (not separately shown) that acts as a manager for the task of performing a simulation. The simulation environment 314 also may implement sub-tasks such as invoking a netlister to create a netlist, assembling and any user-supplied simulation options (such as the time interval over which the simulator is supposed to find a solution (this is an example of an analog control statement, the specification of that particular time interval), or the list of nodes whose waveforms need to be saved to disk by the simulator in order for subsequent viewing in a waveform tool, etc.) The environment also may manage post processing tasks such as waveform inspection, or measurements (e.g. measure a delay time from one signal transition to another) calculated from the simulation results.
In the past, translation of a mixed signal schematic design to a netlist suitable for utilization by a circuit simulation tool has been complicated by insufficient CDF information in many commercially available PDKs. A CDF typically describes the parameters and the attributes of parameters of individual components and libraries of components in a design. While PDK's typically have more complete information (well tested and proven) to enable netlisting to analog netlisting languages such as the SPICE and Spectre, they often have been incomplete or insufficiently tested to fully enable netlisting to the digital netlisting languages such as the VAMS.
FIG. 4 is an illustrative drawing of a netlister 400 to translate a design schematic to VAMS netlist in accordance with certain prior art. A computer system is configured to implement the netlister 400, which includes a netlister module 403 that includes a digital (e.g., Verilog) netlister 402 and an analog (e.g., Spectre) netlister 404, which interact to produce a hybrid netlist. A translator 406 translates the hybrid netlist to a VAMS netlist that is suitable for use in simulation. In operation, the Verilog netlister 404 receives as input schematic design information and reference library information contained in storage devices 410, 412 and traverses the design to produce VAMS language modules. The analog netlister 404 is invoked and receives PDK/CDF information contained in storage devices 414, which it uses to produce an analog design language modules such as SPICE or Spectre modules corresponding to analog instance objects within the design. A map file 418 is produced that maps object names from the analog language namespace to the VAMS namespace, which is the desired end namespace used during simulation. In the illustrative example, Spectre instance statements are wrapped within special tags (e.g., ‘_ANALOG_BEGIN’, ‘_ANALOG_END’) to denote their presence, and the resulting hybrid netlist containsVerilog_AMS instance statements and wrapped Spectre instance statements. The translator 408 acts as a post-processor to search for the specially tagged hybrid statements (wrapped Spectre syntax instance statements using the VAMS namespace) and to translate those statements from the Spectre syntax to VAMS syntax and to replace the hybrid statements with the translated VAMS syntax.
Unfortunately, there have been shortcomings with this prior approach. For example, the example (prior translator 408 processed the tagged analog language statements with incomplete knowledge of surrounding context such as other VAMS statements. More specifically, for example, the translator 408 generally was unaware of sharing of items (such as a net) within a design between a digital component represented with the VAMS language in the hybrid netlist and an analog component represented with the analog language in the hybrid netlist. The analog (e.g., SPICE or Spectre) and digital (e.g., VAMS) languages have different rules for identifying items within a design. As a consequence, a shared item may be identified differently in the digital language and in the analog language. Name clashes sometimes occurred since the translator 408 operated with incomplete knowledge of surrounding Verilog_AMS statements. For example, the translator 408 sometimes would attempt to use the different names for the same item when mapping from Spectre namespace to the VAMS namespace.
Also, for example, the example prior translator 408 performed a line-by-line processing of the tagged statements of the hybrid netlist 416 and relied upon on a simple regular-expression based approach to parsing, which was frequently foiled in the presence of Spectre custom netlisting procedure extensions in a customer's design flow. For example, these custom netlist procedure extensions often reformat the netlist lines, sometimes adding or removing information, renaming objects.
Moreover, the example prior translator 408 failed to update the map file 418 creating difficulty in mapping simulation results to the source schematic design.